\chapter{Robustesse}

\section{Gestion des erreurs}

Les actions demandées à SPASS renvoient toutes un code annonçant le succès ou l'échec, remontant du \textit{core} vers l'API jusqu'au demandeur de l'action.
SPASS n'utilise pas le système d'exceptions de Python, afin de permettre à l'utilisateur un traitement qu'il juge approprié à un échec (un programme de test ou une interface n'ayant pas forcément les mêmes réactions devant un échec).
Les exceptions Python peuvent renvoyer une chaîne de caractères ou un objet. L'utilisation des objets aurait alourdi grandement le code avec la création de multiples classes, qui auraient peut être demandées des modifications pour convenir aux extensibilités futures.
Créer un système de remonté d'erreurs nous permet de donner la main aux \textit{plugins}, tests ou interfaces pour gérer ces retours de manières diverses sans que nous n'imposons de limites avec une implémentation restrictive ou lourde à mettre en place.
Il s'agit donc là de garder le principe d'extensibilité au détriment d'une gestion plus complexe et élaborée.

\section{Environnement d'exécution des tests}

Afin de pouvoir assurer un maximum de sécurité lors du test d'un programme externe, il nous fallait sécuriser l'environnement d'exécution des tests.
Pour ce faire nous avons employé le mécanisme de \textit{fixtures} lancés avant chaque exécution. Recréer un nouvel environnement d'exécution sécurisé pour chaque test permet une robustesse maximum en évitant d'alourdir la sécurité avec des éléments utiles seulement aux autres tests à effectuer.
Ce mécanisme possède néanmoins des défauts tels que n'avoir aucune sécurité par défaut si l'enseignant ne créé pas une \textit{fixture} pour chaque test ou encore forcer un enseignant à dupliquer des \textit{fixtures} car chaque test en nécessite une.
Nous avions d'abord envisagé une\textit{fixture} globale avant de lancer la série de tests, mais cela ne nous semblait pas convenir à une liste de test rendue dynamique de pars le parcours d'arborescence. 
Nous avions ensuite pensé à isoler le processus testé en le faisant tourner dans un environnement créé par \textit{chroot}, mais nous en sommes vite arrivé à nous demander si cela n'était pas inutile. 
En reprenant l'exemple du solveur de sudoku, il nous apparaissait clairement qu'isoler le processus pour lui soumettre une série de grilles est tout bonnement inadapté.
C'est de cette base que nous sommes partis pour choisir d'utiliser une \textit{fixture} par test.

\section{Internationalisation}

SPASS est un programme qui se veut évolutif, et nous avons voulu pousser cette possibilité d'évolution jusqu'à la langue utilisée.
Pour ce faire, nous avons utilisé un procédé simple proche de celui utilisé en C avec la variable \textit{errno}: nous envoyons des codes d'erreurs ou de messages auxquels nous associons une chaîne de caractères.
Ainsi, il suffit de rajouter la structure d'association traduite dans la langue voulue afin de permettre la traduction.
Évidement, pour choisir la bonne langue, il faudrait rajouter une variable d'environnement dans \textit{settings.py} afin de permettre le choix de la bonne structure d'association afin de finaliser le système. 
Ce point n'ayant pas fait parti des besoins, nous n'avons fait que donner la possibilité de l'utiliser simplement en rajoutant une variable globale de langue, actuellement, l'association n'existe qu'en une seule langue.

\chapter{Tests}

\section{Tests manuels}

\subsection{Test de performance}

Une de nos stratégies d'implémentation pour le module \emph{commands} a été la recherche dynamique dans la hiérarchie de fichier. Cela implique pour SPASS d'effectuer des accès au disque dur à chaque fois qu'un(e) \textit{plugin}/commande est exécuté(e). Cela pose naturellement un problème de performance en temps d'exécution. L'autre méthode aurait été de fournir le chemin d'exécution, mais cela implique l'ajout de tests supplémentaires (soucis de robustesse).

Nous avons donc effectué un test de performance : temps d'exécution mis par SPASS en fonction du nombre de \textit{plugins} à charger. Ce test a été effectué sur une machine "grand public" (processeur à 2 coeurs, 4 giga octets de mémoire vive, disque dur 7200 rpm).

\paragraph{}

\includegraphics[scale=0.95]{perfo}

\emph{Chaque valeur en ordonnée est la moyenne de 5 prises de valeurs}
\paragraph{}

On constate que la différence entre le temps de chargement d'un seul \textit{plugin} et trois cents \textit{plugins} ne diffère que de l'ordre de 5 centièmes de seconde, ce qui reste négligeable pour l'utilisateur. La solution du parcours dynamique (de la hiérarchie des fichiers) a donc été choisi au détriment d'un chargement statique qui reste moins intuitif à l'utilisation (et surtout plus enclin à générer des erreurs).

\subsection{Test de couverture fonctionnelle}

Après chaque implémentation d'une nouvelle fonctionnalité de SPASS (nouvelle \textit{builtin} par exemple), un test de la dite fonctionnalité a été systématiquement réalisé.
A son stade final, un nouveau test de couverture complet a été réalisé (avec tous les cas possibles) pour vérifier que tous les modules réagissaient en harmonie. Cela ne supprime tout de même pas la possibilité éventuelle de la présence d'un bogue caché.

\section{Tests automatisés}

\subsection{Pylint}

\textit{Pylint} nous a été d'une grande aide pour le nettoyage du code. Il nous a permis de corriger un nombre incalculable d'\emph{import} bouclés (silencieux à l'exécution), de variables et paramètres inutilisés. Ci-dessous, le rapport généré par \textit{Pylint} :

\texttt{\small{\lstinputlisting{report.txt}}}

La note donnée à titre indicatif par \textit{Pylint}, indiquait \textit{-4.72/10} avant le refactoring du code.

\subsection{Pychecker}

\textit{Pychecker} est un autre analyseur de code Python, très similaire à \textit{Pylint}.
Après le passage au test avec \textit{Pylint}, il ne restait guère
d'erreurs/avertissements sur le code. Néanmoins quelques avertissements
de variables/paramètres/modules non-utilisés subsistaient.
